An overlay based on, e.g., VXLAN (Virtual Extensible LAN), may be used to virtualize a network's physical infrastructure. An overlay requires the data path at the edge of the network to map from the Tenant end-point address in the packet, a.k.a. its “identifier,” to the location of the end-point, a.k.a. its “locator”. This mapping occurs in a function that may be referred to as a “Tunnel End-Point” or TEP.
The challenge of with this mapping is how to scale it for very large, high performance data centers. The first problem with scale is that this mapping state must exist in a large number of locations or TEPs. The mapping must be done in every TEP where an end-point exists that wants to send a packet across the network to another end-point. Potentially, this is at every ingress point in the network.
The second problem with scale is that when an end-point moves, i.e. its locator changes, the mapping state must be updated across the network in all TEPs that have that mapping.
One typical solution is to propagate the mapping to all the TEPs all the time, including changes. A variation on this is to pull the mapping state from a centralized database when it is needed triggered by an exception in the TEP. This latter approach typically has some difficulty in handling end-point movement, i.e. the mapping being out-of-date. Both of these solutions suffer from scale limitations imposed by the central entity that holds the authoritative database of all mappings. It either has too much latency, not enough capacity, or is too expensive. Another issue with this kind of implementation is that it can be difficult to push state to a large number of locations reliably. In large systems, it is almost guaranteed that some failures will occur when pushing the state and then the system has to deal with inconsistent state.
Another approach is to utilize layer 2 semantics and do a “Flood and Learn” where packets that are addressed to end-points whose identifier to locator mapping is not known at the ingress TEP are flooded to all egress TEPs where the end-point may exist. The locator to identity mapping of the source of the tunneled packet is then learned at the egress TEP so that subsequent traffic in the reverse direction does not have to be flooded. This solution has the problem that flooding behavior is generally considered to be very bad because of packets being sent to devices that do not want to see them, and it does not nicely support routing semantics in the fabric because you would not want to flood across a router. In addition, this solution does not address the problem with an end-point moving and the previously learned state being out of date.